Software source code development/generation is an iterative process. From the time of conception to release of a program for distribution to the public, source code files making up the program undergo many rounds of changes. At each round, new sets of revisions (or “revised files”) are submitted and stored within a software configuration management system. After storing an initial version of source code for a program, subsequent sets of revisions are submitted on top of prior revision file sets and constitute a current revision of the program's source code. Such revision file sets are tracked by software source code development tools generally referred to as software configuration management (SCM) systems. Other names given to such systems include “source control system”, “version control system”, and “revision control system”. In SCM systems, a set of revisions for a set of files are submitted as a group to the SCM system. The SCM system then incorporates those changed files into a previous current revision of the source code to render a new current revision of the source code.
After incorporating the set of revisions to render a current revision of computer program source code, the source code is compiled to render an executable corresponding to the current revision of the program source code. Assuming compiler errors do not arise during the compiling process, (requiring yet another revision including further changes to the source code files) an executable is rendered that corresponds to the current revision of the source code files for a program. The executable is exercised in a test environment and a list of action items are rendered from testing/reviewing the operation of the executable.
Ideally, each set of changes contained in a latest revision of source code improves the operation of, or corrects a flaw within, the prior revision of the source code. However, in reality changes to earlier versions/revisions are not always desirable, and it becomes necessary to identify and undo at least some of the changes embodied within earlier revisions. Furthermore, program source code can go through multiple revisions, maintained by an SCM system, before a determination is made that earlier changes resulted in undesirable program operation.
Tracking a single set of changes between two consecutive revisions of program source code is relatively easy. However, tracking changes through multiple revisions is more complicated. In prior systems, one type of change, “undoing” one or more prior revisions by deleting the revisions (and any associated changes contained therein) from the revision history maintained by the SCM system, can be especially unnerving since such undoing of a revision removes all indications of the revision (and its particular changes) from the SCM system. If the “undoing” act is unsuccessful in remedying the flaw and the programmer seeks to return the software source code to its state before the “undoing” procedure was performed, then the programmer must re-create the revision from a source other than the SCM system.
The task of tracking and undoing changes to source code embodied in revisions is further complicated when supporting integration history (which describes changes submitted to render a revision of a source code file by specifying changes incorporated into a range of revisions to another file or files). A known SCM system, SOURCE DEPOT, as well as other SCM systems, support integration history.